A virtual machine (VM) is software that acts as an interface between (normally platform-neutral) code (bytecode) and the hardware that actually executes machine instructions. A Java™ VM created by Sun Microsystems, Inc. of Palo Alto, Calif. is an example of a VM. Modern VMs, at least large ones that run on desktop machines and servers, normally support a lot of execution parameters, specified in the form of command line options. An example of such a VM is the HotSpot™ Java™ VM. These options are read at the VM startup time, and affect the VM behavior during runtime. For example, one may set initial and maximum memory heap size and choose whether to print various types of trace (logging) information.
The value of an execution parameter can be set via a corresponding command line option only once, at the VM startup, and there is no provision for changing its value afterwards. For some execution parameters this does not present a problem, since it is impossible to alter the corresponding setting at runtime (for example, options specifying the dynamic compiler to use, or effectively a dynamic library to load at startup in the HotSpot™ Java™ VM). On the other hand, there are a number of execution parameters for which it would make sense and be technically feasible to change, maybe many times, at runtime. Trace information printing is an example of an option which is usually easy and safe to turn on and off many times during VM execution.
It would make particular sense for system administrators and developers to be able to alter at runtime those VM execution parameters that affect VM serviceability, for example allowing client tools to attach to the running VM and introspect its code and data. This would allow “in the field” debugging and monitoring of applications running on a VM that was not originally configured to support these kinds of activity.
Hence it is desirable to be able to alter at least some of the execution parameters of a VM at runtime.